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Scope 



The present document describes the signalling behaviour of the transport functions BTF & RCEF for the listed multicast 
and unicast transport control protocols (IGMP, MLD, RSVP) and Diameter Re and provides a mapping between these 
multicast and unicast transport control protocols and the TISPAN RACS Re interface. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] IETF RFC 2205: "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification". 

[2] ETSI TS 183 060: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control Subsystem (RACS); 
Re interface based on the DIAMETER protocol". 

[3] IETF RFC 3181: "Signaled Preemption Priority PoHcy Element". 

[4] IETF RFC 3182: "Identity Representation for RSVP". 

[5] IETF draft-ietf-tsvwg-rsvp-proxy-proto: "RSVP Extensions for Path-Triggered RSVP Receiver 

Proxy". 

[6] IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

[7] IETF RFC 2236: "Internet Group Management Protocol, Version 2". 

[8] IETF RFC 3810: "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

termination point: element acting as the neighbouring multicast router receiving and handling IGMP/MLD request 
from the UE 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AF Application Function 

A-RACF Access-Resource and Admission Control Function 

BTF Basic Transport Functions 

CAC Connection Admission Control 

CCA Credit-Control-Answer 

CCR Credit-Control-Request 

CPN Customer Premises Network 

IGMP Internet Group Management Protocol 

IPTV Internet Protocol Television 

MLD Multicast Listener Discovery 

QoS Quality of Service 

RACS Resource and Admission Control Subsystem 

RCEF Resource Control Enforcement Function 

RSVP Resource ReSerVation Protocol 

UE User Equipment 



4 Overview 

4.1 Overview of multicast transport control protocol to Re 
mapping 

PULL mode for multicast applies in two cases: 

• PULL mode case 1 : when it applies below the termination point in the access segment, the PULL mode is used 
to request resources for a channel in the access network and/or to indicate that the resources associated to a 
channel can be released as the channel is left. This is per user and can be combined with the PUSH mode at 
session initiation to allow the A-RACF to download the permitted multicast flow for that user to the RCEF. 

• PULL mode case 2: when it applies beyond the termination point, the PULL mode is used to request shared 
resources to transport a multicast flow corresponding to a channel that has been requested by one or more 

users. 

The following figure shows a generic scenario for both cases of PULL mode. Transport processing nodes comprises one 
or several RTFs and one or several RCEFs that may be colocalised. 
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Figure 4.1 : A generic scenario for both cases of PULL mode 

1) Upon session activation, the RACS downloads the policy rules in the RCEF in charge of enforcing policies 
applicable to the access segment. This corresponds e.g. to the list of subscribed channels in case of IPTV 
service activation. For each policy, bandwidth is set to zero, this will force the transport processing node to 
trigger the PULL mode. 

2) The BTF receives a multicast request. This message may contain IGMP/MLD "leave" and/or "join" requests. 

3) The BTF requests CAC towards the RCEF. The RCEF checks that the requested channel corresponds to an 
existing policy-rule. If not, it ignores the request and the user will not receive the channel. If a policy-rule 
exists, and if PULL mode applies below the termination point, the RCEF sends a CC-Request to the RACS 
based on parameters received in the multicast request. It has therefore to indicate to the RACS that the UE 
wants to leave a particular channel and/or wants to join another one. If enough resource is available to join the 
requested channel, the RACS answers positively to the RCEF. 

4) If the step 3 is successful, the BTF forwards the request to the RCEF dealing with resource beyond the 
termination point. If PULL mode applies beyond the termination point, the RCEF sends a CC-Request to the 
RACS based on parameters received in the multicast request. It does not have to check any policy-rule 
previously downloaded because this request is not linked to any user's rights. The RACS can determine if 
enough resource is available in the aggregation segment. If this is the case, the RACS answers positively to the 
RCEF. 

4.2 Overview of unicast transport control protocol to Re 
mapping 

The mapping between unicast transport control protocol and Re may be invoked in the Push Mode or the Pull Mode. An 
overview is provided below for both cases. 

The mapping is defined with RSVP ([!]) as the unicast transport control protocol. 

4.2.1 Push IVIode 

Figure 4.2 illustrates the RSVP to Re mapping in Push Mode with on-path QoS reservation in the case of a successful 
reservation establishment. 
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Figure 4.2: RSVP to Re mapping in Push IVIode with on-path QoS reservation 

1) As a result of a request from the AF for admission and resource reservation, the RACS sends a 
Policy-Install-Request to the RCEF in order to install a policy rule into the Transport Processing Nodes. 

2) In the Push mode with on-path QoS signaling, the RCEF communicates the request to the BTF that issues an 
RSVP Path message to initiate path-coupled QoS signaling in order to establish the necessary reservation in 
the Transport Processing Nodes. 

3) On receipt of an RSVP Resv message, the BTF communicates the reservation establishment to the RCEF. 

4) The RCEF sends a Policy-Install- Answer to the RACS to confirm policy rule installation in the Transport 
Processing Nodes. 

4.2.2 Pull Mode 

Figure 4.3 illustrates the RSVP to Re mapping in Pull Mode in the case of a successful reservation establishment. 
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Figure 4.3: RSVP to Re mapping in Pull Mode 
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1) The BTF receives an RSVP Path message corresponding to a path-coupled QoS reservation initiation request 
from a Transport Node (e.g. a CPN Device). The BTF communicates the request to the RCEF. 

2) The RCEF sends a CCR request to the RACS to request authorization of the reservation initiation request 
based on parameters mapped from the RSVP Path message. 

3) The RCEF responds to the RCEF with a CCA to confirm that the reservation initiation request is authorized. 
The RCEF confirms the authorization decision to the BTF. 

4) The BTF ft)rwards the RSVP Path message towards the reservation destination. 

5) The BTF receives an RSVP Resv message requesting reservation establishment. After successfril RSVP 
reservation establishment, the BTF communicates the resource reservation establishment to the RCEF. 

6) The RCEF sends a CCR request to the RACS to request resource reservation based on parameters mapped 
from the RSVP Resv message. 

7) The RACS responds to the RCEF with a CCA to confirm the reservation establishment. The RCEF 
communicates the establishment decision to the BTF. 

8) The BTF forwards the RSVP Resv message towards the reservation source. 



5 Behaviours of the transport functions for multicast 

5.1 PULL mode: case 1 

On reception of an IGMPv3/MLDv2 request, the BTF communicates the request to the RCEF. If the type is set to 0x22 
" v3 Membership Report" in case of IGMPv3 or to 143 "Version 2 Multicast Listener Report" in case of MLDv2, the 
RCEF shall take the following actions for each Group/multicast Records present in the request: 

• If Record Type indicates ALLOW_NEW_SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields, the RCEF shall check for each multicast 
address/source address pair if it corresponds to an existing policy rule. If not, the RCEF shall ignore the 
request for that pair. If this is the case, the RCEF shall consider that the UE wants to join the corresponding 
multicast flow and shall send a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. 

• If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty 
source list, the RCEF shall consider that the UE wants to leave the corresponding multicast flow and shall send 
a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. 

On reception of an IGMPv2 request, the BTF communicates the request to the RCEF. 

If the type is set to 0x16 "v2 Membership Report", the RCEF shall consider that the UE wants to join the corresponding 
multicast flow and shall take the following actions: 

• If the multicast address indicated in the Group Address parameter corresponds to an existing policy rule, the 
RCEF shall consider that the UE wants to join the corresponding multicast flow and shall send a CC-Request 
applying the mapping defined in clause 6.1 for IGMPv2. 

• If not, the RCEF shall ignore the request for that pair. 

If the type is set to 0x17 "Leave Group", the RCEF shall consider that the UE wants to leave the corresponding 
multicast flow and shall send a CCR request applying the mapping defined in clause 6.1 for IGMPv2. 

On receipt of a CC-Answer, the RCEF shall behave as defined in TS 183 060 [2]. 

For each Policy-Rule-Install AVP that corresponds to a previously reported Policy-Update-Request in the CCR, the 
RCEF shall update the Max-Requested-Bandwidth-DL for the corresponding policy based on the value received from 
the A-RACF. If the value is set to zero, the BTF shall not forward the corresponding multicast fiow. 
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5.2 PULL mode: case 2 

On reception of an IGMPv3/MLDv2 request, the BTF communicates the request to the RCEF. If the type is set to 0x22 
"v3 Membership Report" in case of IGMPv3 or to 143 "Version 2 Muhicast Listener Report" in case of MLDv2, the 
RCEF shall take the following actions for each Group/multicast Records present in the request: 

• If Record Type indicates ALLOW_NEW_SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields, the RCEF shall check for each multicast 
address/source address pair if the corresponding multicast flow is already received. If it is the case, the RCEF 
shall ignore the request for that pair. If not, the RCEF shall send a CC-Request applying the mapping defined 
in clause 6.2 for IGMPv3/MLDv2. 

• If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty 
source list, the RCEF shall check if other UE are still requesting the corresponding multicast flow. If not, the 
RCEF may send a CC-Request applying the mapping defined in clause 6.2 for IGMPv3/MLDv2. 

NOTE: The way the transport functions know that a channel is not required by any other UEs is based on 

Membership Query mechanisms as defined in RFC 3376 [6] (IGMPv3) and RFC 2236 [7] (IGMPv2) and 
based on Membership Listener query mechanisms as defined in RFC 3810 [8] (MLDv2). 

On reception of an IGMPv2 request, BTF communicates the request to the RCEF. 

If the type is set to 0x16 "v2 Membership Report", the RCEF shall check if the requested multicast address indicated in 
the Group Address parameter is already received. If it is the case, the RCEF shall ignore the request. If not, the RCEF 
shall send a CC-Request applying the mapping defined in clause 6.2 for IGMPv2. 

If the type is set to 0x17 "Leave Group", the RCEF shall consider that the UE wants to leave the corresponding 
multicast flow and shall check if other UEs are still requesting the corresponding multicast flow. If not, the RCEF may 
send a CC-Request applying the mapping defined in clause 6.2 for IGMPv2. 

On receipt of a CC-Answer, the RCEF shall behave as defined in TS 183 060 [2]. 

For each Policy-Rule-Install AVP that corresponds to a previously reported Flow-Description, the RCEF shall create 
the corresponding policy. The transport function shall forward the corresponding multicast fiow applying QoS 
parameters defined in the Policy-Rule-Install AVP. For any previously reported Flow-Description that does not receive 
any corresponding PoUcy-Rule-Install AVP, the BTF shall not forward the corresponding multicast flow. 



6 Multicast to Re parameters mapping 

6.1 PULL mode: case 1 

When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.1 for IGMPv3/MLDv2 
request. 

Table 6.1 : Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 1 



CCR AVPs 


Derivation from IGI\/IPv3/MLDv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-Update-Request 


For each multicast/source address: 

• Policy-rule-Name shall be set to the corresponding policy rule name for that pair. 

• Policy_rule_status shall be set to ACTIVE. 

• if Record Type indicates ALLOW NEW SOURCE with INCLUDE filter mode or 
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields: 

o IVIax-Requested-Bandwidth-UL shall be set to zero. 

o IVIax-Requested-Bandwidth-DL shall be set to FFFFFFFF. 

• if Record Type indicates BLOCK OLD SOURCE or 
CHANGE_TO_INCLUDE_MODE with an empty source list: 

o IVIax-Requested-Bandwidth-UL shall be set to zero. 
o IVIax-Requested-Bandwidth-DL shall be set to zero. 
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When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.2 for IGMPv2 request. 
Table 6.2: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 1 



CCR AVPs 


Derivation from IGMPv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-Update-Request 


• Policy-rule-Name shall be set to the corresponding policy rule name for that group 
address indicated in the request. 

• Policy_rule_status shall be set to ACTIVE. 

• If the type is set to 0x1 6 "v2 IVIembership Report": 

o IVIax-Requested-Bandwidth-UL shall be set to zero. 

o IVIax-Requested-Bandwidth-DL shall be set to FFFFFFFF. 

• If the type is set to 0x1 7 "Leave Group": 

o IVIax-Requested-Bandwidth-UL shall be set to zero. 
o IVIax-Requested-Bandwidth-DL shall be set to zero. 



6.2 



PULL mode: case 2 



When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.3 for IGMPv3/MLDv2 
request. 

Table 6.3: Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 2 



CCR AVPs 


Derivation from IGIVIPv3/MLDv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Framed-IP address 


It shall set to termination point IP address. 


Physical-Access-ld 


It shall not be present. 


Logical-Access-ld 


It shall not be present. 


User-Name 


It shall not be present. 


Calied-station-ID 


It shall not be present. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-rule-Report 


If the flow is already received, for each multicast/source address: 

• Policy-rule-Name shall be set to the corresponding policy rule name for that pair. 

• If Record Type indicates BLOCK_OLD_SOURCE or 

CHANGE TO INCLUDE MODE with an empty source list, Policy-Rule-status shall 
be se to INACTIVE. 


Flow-Description 


If the flow is not already received, for each multicast/source address: 

• Direction shall be set to "in". 

• Destination address shall be set to the "multicast address". 

• Source address shall be set to the Source address if present. 

• Source and Destination port shall be not be supplied. 



When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.4 for IGMPv2 request. 
Table 6.4: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 2 



CCR AVPs 


Derivation from IGMPv2 Parameters 


CC-Request-Type 


It shall be set to UPDATE REQUEST. 


Event-Trigger 


It shall be set to RESOURCES MODIFICATION. 


Policy-rule-Report 


If the flow is already received: 

• Policy-rule-Name shall be set to the corresponding policy rule name for the Group 
Address indicated in the request. 

• If the type is set to 0x17 "Leave Group" Policy-Rule-status shall be se to INACTIVE. 


Flow-Description 


If the flow is not already received: 

• Direction shall be set to "in". 

• Destination address shall be set to the Group Address parameter. 

• Source address shall not be supplied. 

• Source and Destination port shall be not be supplied. 



£75/ 



1 2 ETSI TS 1 83 067 V3.1 .1 (2009-1 1 ) 

7 Behaviours of the transport functions for unicast 

7.1 Push mode (RACS initiated Procedures) 

This clause specifies the behavior of the RSVP transport functions for unicast in the case of Push mode with on-path 
QoS reservation. 

7.1 .1 Handling Policy-lnstall-Request from RACS 

On receipt of a Policy-lnstall-Request from RACS, the RCEF shall process the message as specified in TS 183 060 [2]. 
In addition, when operating in the Push mode with on-path QoS reservation, the RCEF shall extend this behavior as 
defined in clause 7.1.1.1 (respectively clauses 7.1.1.2 and 7.1.1.3) in case of policy activation (respectively policy 
modification and policy deactivation). 

7.1 .1 .1 Activation of a Policy Rule 

On receipt of a Policy-lnstall-Request with Pi-Request-Type AVP containing the value INITIAL_REQUEST that 
activates a new Policy Rule with Flow-Status ENABLED-DOWNLINK, the RCEF shall consider that a new on-path 
QoS reservation is to be initiated for each IP Flow defined in a Flow-Description AVP. The RCEF shall communicate 
with the BTF to ensure that an RSVP Path message is transmitted. The parameters in the RSVP Path message shall be 
mapped from those of the PIR command in accordance with table 8.1. 

The BTF is responsible for refreshing the RSVP path state in accordance with RSVP procedures during all the time that 
the corresponding Policy Rule is maintained active by the RACS. 

7.1 .1 .2 Policy Modification 

On receipt of a PoUcy-Install-Request with the Pi-Request-Type AVP set to UPDATE_REQUEST, and a 
Policy-Rule-Install AVP specified (with Flow-Status ENABLED-DOWNLINK), the RCEF shall consider that the 
existing on-path QoS reservation for each IP Flow is to be modified. The RCEF shall communicate with the BTF to 
ensure that an RSVP Path message is re-signalled for each such existing on-path QoS reservation. The parameters in the 
RSVP Path message shall be mapped using the same mapping rules as used for establishment of an initial on-path 
QoS reservation (i.e. in accordance with table 8.1). 

On receipt of a Policy-lnstall-Request with the Pi-Request-Type AVP set to UPDATE_REQUEST, and a 
Policy-Rule-Install AVP (with Flow-Status REMOVED) or a Policy-Rule-Remove AVP specified, the RCEF shall 
consider that the existing on-path QoS reservation for each IP Flow is to be torn down. The RCEF shall communicate 
with the BTF to ensure that an RSVP PathTear message is transmitted for each such existing on-path QoS reservation. 
The parameters in the RSVP PathTear message shall be the same as those used in the Path messages that were sent 
previously for the corresponding on-path QoS reservation. The BTF shall then communicate with the RCEF to confirm 
that the on-path QoS reservation has been torn down. Then, assuming all the other processing of the 
Policy-lnstall-Request as defined in [2] is successful, the RCEF shall return a Policy-Install- Answer to the RACS with 
the Result-Code AVP set to DIAMETER_SUCCESS. 

7.1 .1 .3 Deactivation of a Policy Rule 

On receipt of a PoUcy-Install-Request with Pi-Request-Type AVP set to TERMINATION_REQUEST, if the 
terminated Policy Rule(s) had a Flow-Status ENABLED-DOWNLINK the RCEF shall consider that the corresponding 
on-path QoS reservation for each IP Flow is to be torn down. The RCEF shall communicate with the BTF to ensure that 
an RSVP PathTear message is transmitted for each such existing on-path QoS reservation. The parameters in the RSVP 
PathTear message shall be the same as those used in the Path messages that were sent previously for the corresponding 
on-path QoS reservation. 

The BTF shall then communicate with the RCEF to confirm that the on-path QoS reservation has been torn down. Then, 
assuming all the other processing as defined in [2] is successful, the RCEF shall return a Policy-Install-Answer to the 
RACS with the Result-Code AVP set to DIAMETER SUCCESS. 
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7.1 .2 Handling unicast transport control protocol events 

7.1.2.1 RSVP Reservation establishment 

On receipt of an RSVP Resv message for a new, or a modified on-path QoS reservation, the BTF shall process the 
RSVP message as per procedures specified in [1]. On successful establishment of the Resv state, the BTF shall notify 
the RCEF. Then, assuming all the other processing of the corresponding Policy-Install-Request as defined in [2] is 
successful, the RCEF shall return a Policy-Install- Answer to the RACS with the Result-Code AVP set to 
DI AMETER_S UCCES S . 

The BTF is responsible for managing the soft state of the RSVP Resv state. This includes handling received RSVP Resv 
refresh messages and processing of those in accordance with RSVP procedures. This also includes detecting time-out of 
the Resv state and handling of this situation as defined in clause 7.1.1.4. 

7.1.2.2 RSVP Reservation Reject/Establishment Failure/Modification Failure 

On receipt of an RSVP message indicating that a new on-path QoS reservation establishment has been rejected 
(e.g. receipt of a PathErr message containing an ERROR_SPEC object with an error code of "Code 1 - Admission 
Control Failure" or "Code 2 - Policy Control Failure" as specified in [5]) or has failed possibly after appropriate 
re-attempts (e.g. a corresponding Resv message is not received in a timely manner) for an on-path QoS reservation that 
the BTF is attempting to establish, the BTF shall communicate this to the RCEF. In turn, the RCEF shall return a 
Policy-Install-Answer to the RACS with the Experimental-Result-Code AVP set to 

POLICY_ACTIVATION_FAILURE. The RCEF shall set the Rule-Failure-Code AVP within the Policy-Rule-Report 
AVP to RESOURCES_LIMITATION. The RCEF may include in the Error-Message AVP the following string: 

• "On-Path reservation Admission Control Failure" in case of a PathErr message with an ERROR_SPEC 
containing an error code "Code 1- Admission Control Failure". 

• "On-Path reservation Policy Control Failure" in case of a PathErr message with an ERROR_SPEC containing 
an error code "Code 2- Policy Control Failure". 

• "On-Path reservation failure because of Transport Network reasons" in the other cases of QoS reservation 
failure. 

The BTF should remove the corresponding Path state in the transport nodes by issuing an RSVP PathTear message 
(with the same parameters as the corresponding Path messages) unless the BTF knows that the path state has already 
been removed or never got established. 

On receipt of an RSVP message indicating that an on-path QoS reservation modification (e.g. reservation bandwidth 
increase) has been rejected but that the original reservation has been maintained (.i.e. on receipt of a PathErr with the 
InPlace flag set in the ERROR_SPEC as specified in [5]), the BTF shall communicate this to the RCEF. In turn, the 
RCEF shall return a Policy-Install-Answer to the RACS with the Experimental-Result-Code AVP set to 
POLICY_MODIFICATION FAILURE. The RCEF shall set the Rule-Failure-Code AVP within the Policy-Rule-Report 
AVP to RESOURCES_LIMITATION. The RCEF may include in the Error-Message AVP the following string: 

"On-Path QoS reservation modification Admission Control Failure" in case of a PathErr message with an 
ERROR_SPEC containing an error code "Code 1- Admission Control Failure". 

"On-Path QoS reservation modification Policy Control Failure" in case of a PathErr message with an 
ERROR_SPEC containing an error code "Code 2- Policy Control Failure". 

"On-Path reservation failure because of Transport Network reasons" in the other cases of QoS reservation 
modification failure. 



• 



• 



The BTF shall maintain the Path state corresponding to the original QoS reservation. 

7.1 .2.3 RSVP Reservation Loss/Tear-Down 

The BTF shall detect the loss or teardown on an existing on-path QoS reservation that the RCEF established. The 
detection is based on existing RSVP procedures as specified in [2] and [5]. For example, this includes time-out of 
received Resv refreshes or receipt of an RSVP PathErr containing an ERROR_SPEC object with an error code of 
"Code 1 - Admission Control Failure" or "Code 2 - Policy Control Failure". 
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In case the BTF deems that attempting to re-establish the reservation is likely to succeed, the BTF may optionally 
re-attempt such reestablishment by resending an RSVP Path message with corresponding parameters. If that attempt 
fails, or if the BTF deems that re-attempting reservation establishment is unlikely to succeed, the BTF shall notify the 
RCEF that the on-path QoS reservation has been torn down. In turn, the RCEF shall generate an event towards the 
RACS (assuming explicit or implicit subscription of RACS for this event type). The event is of type 
LOS S_OF_B BARER. The RCEF shall set the Rule-Failure-Code AVP within the Policy-Rule-Report AVP to 
RESOURCES_LIMITATION. The RCEF may include in the Error-Message AVP the following string: 

• "On-Path Reservation Admission Control Failure" when the BTF detects the loss of reservation by receipt of a 
PathErr containing an ERROR_SPEC with an error code of "Admission Control Failure". 

• "On-Path Reservation Policy Control Failure" when the BTF detects the loss of reservation by receipt of a 
PathErr containing an ERROR_SPEC with an error code of "Policy Control Failure". 

• "On-Path QoS reservation failure because of Transport Network reasons" when the BTF detects the loss of 
reservation by any other means (e.g. Resv Refresh time-out). 

The BTF should remove the Path state for the reservation that was lost or torn downs by issuing an RSVP PathTear 
message (with the same parameters as the corresponding Path messages) unless it knows the Path state has already been 
torn down. If there are on-path QoS reservations for flows corresponding to the same Policy-Install-Request, the RCEF 
shall tear down these reservations by issuing an RSVP PathTear message for each other reservation. 

7.2 Pull mode (RCEF initiated Procedures) 

7.2.1 Reservation pre-authorization 

NOTE: The current release does not specify reservation pre-authorization for unicast pull-mode. 

7.2.2 Reservation establishment in pull mode 

On receipt of an RSVP Resv message for a new on-path QoS reservation, the BTF shall process the RSVP message as 
per procedures specified in [1]. In case of RSVP message processing failure, the BTF shall behave in accordance 
with [1] (e.g. generate a ResvErr). In case of successful message processing, the BTF shall notify the RCEF. The RCEF 
shall then send a CCR request to the RACS to request actual reservation of the corresponding resources. The parameters 
in the CCR request shall be mapped from those of the RSVP Resv message in accordance with table 8.2, the 
CC-Request-Type AVP shall be set to INITIAL_REQUEST and the Flow-Status shall be set to 
ENABLED-DOWNLINK. 

The RACS shall respond to the RCEF with a CCA indicating whether the resource reservation was successfully 
performed by RACS. 

If the resource reservation is authorized by RACS, the RACS shall send a CCA with a Result-Code AVP set to 
DIAMETER_SUCCESS. The RCEF shall then confirm the positive decision to the BTF. In turn, the BTF shall forward 
the RSVP Resv message towards the reservation destination. 

If the resource reservation is not authorized by RACS, the RACS shall send a CCA with a Result-Code AVP set to 
DIAMETER_AUTHORIZATION_REJECTED. The RCEF shall then communicate the negative decision to the BTF. 
In turn, the BTF shall generate a ResvErr message with an ERROR_SPEC object whose Error Code is set to Policy 
Control Failure and shall not forward the Resv message. 

7.2.3 Reservation Loss/Tear- Down 

The BTF shall detect the loss or tear-down on an existing on-path QoS reservation. The detection is based on existing 
RSVP procedures as specified in [2] and [5]. For example, this includes: 

• time-out of received Resv refreshes; 

• receipt of a ResvTear; 

• receipt of an RSVP PathErr containing an ERROR_SPEC object with an error code of "Code 1 - Admission 
Control Failure" or "Code 2 - Policy Control Failure"; 

• receipt of a PathTear. 
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The BTF shall notify the RCEF of such reservation loss or tear-down. In turn, the RCEF shall send a CCR request to the 
RACS to notify RACS of the resource reservation termination. The CC-Request-Type AVP in this CCR shall be set to 
TERMINATION_REQUEST. The RACS shall release the corresponding resources and respond to RCEF with a CCA 
with Result-Code AVP set to DIAMETER_SUCCESS. 

7.2.4 Reservation Modification 

The BTF shall detect the modification of an existing on-path QoS reservation (i.e. the change of one or more reservation 
parameters specified in the received Resv message). The BTF shall first process the RSVP message as per procedures 
specified in [1]. In case of RSVP message processing failure, the BTF shall behave in accordance with [1] (e.g. generate 
a ResvErr). In case of successful message processing, the BTF shall notify the RCEF of the reservation modification. 
The RCEF shall then send a CCR request to the RACS to request reservation adjustment of the corresponding 
resources. The parameters in the CCR request shall be mapped from those of the RSVP Resv message in accordance 
with table 8.2 and the CC-Request-Type AVP shall be set to UPDATE_REQUEST. 

The RACS shall respond to the RCEF with a CCA indicating whether the resource reservation was successfully 
modified by RACS. 

If the resource reservation modification is authorized by RACS, the RACS shall send a CCA with a Result-Code AVP 
set to DIAMETER_SUCCESS. The RCEF shall then confirm the positive decision to the BTF. In turn, the BTF shall 
forward the RSVP Resv message towards the reservation destination. 

If the resource reservation is not authorized by RACS, the RACS shall send a CCA with a Result-Code AVP set to 
DIAMETER. AUTHORIZATION_REJECTED. The RCEF shall then communicate the negative decision to the BTF. 
In turn, the BTF shall generate a ResvErr message with an ERROR_SPEC object whose Error Code is set to Policy 
Control Failure and shall not forward the Resv message. 
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8 



RSVP to Re parameters mapping 



8.1 



Push Mode 



8.1 .1 Re PI R to RSVP Path Parameter Mapping 

When, in accordance with clause 7.1.1.1, the RCEF/BTF sends an RSVP Path message to initiate an on-path QoS 
reservation as a result of a received Policy-Install-Request from RACS, the mapping defined in the following table shall 
be used: 

Table 8.1 : Re PIR to RSVP Path Parameter mapping 



RSVP Objects 


Derivation from PIR AVPs 


SESSION 


It shall be mapped from the Policy-Rule-lnstall AVP ->Policy-Rule-Definition AVP -> Flow- 
Description AVP: 

• Destination IP Address shall be set to Flow-Description AVP 
->Destination IP Address. 

• Protocol shall be set to Flow-Description AVP 
->Protocol. 

• Destination Port shall be set to Flow-Description AVP 
->Destination Port. 


SENDER_TEMPLATE 


It shall be mapped from the Policy-Rule-lnstall AVP ->Policy-Rule-Definition AVP -> Flow- 
Description AVP: 

• Sender IP Address shall be Flow-Description AVP 
->Source IP Address. 

• Sender Port shall be set to Flow-Description AVP 
->Source Port. 


SENDER_TSPEC 


The RSVP Peak Data Rate [p] shall be mapped from Policy-Rule-lnstall AVP 
->Policy-Rule-Definition AVP ->QoS-lnformation AVP: 

• Peak Data Rate shall be computed from the Flow-Description AVP 

-> Max-Requested-Bandwidth-DL. The Peak Data Rate shall be expressed in 
bytes/sec. It shall include IP headers but shall not include Layer-2 headers or any 
other Layer-2 overheads. 
The RSVP Token Bucket Rate [r] shall be mapped from Traffic-Descriptor-DL AVP: 

• Token Bucket Rate shall be computed from the Traffic-Descriptor-DL-> 
Committed-Data-Rate. The Token Bucket Rate shall be expressed in bytes/sec. It 
shall include IP headers but shall not include Layer-2 headers or any other Layer- 
2 overheads. 

The other SENDER_TSPEC parameters may be mapped from the Traffic-Descriptor-DL 
AVP or from the traffic class identified by the TOS-Traffic-class AVP. 


POLICY_DATA 
(Preemption [3], 
AUTH USER [4], 

AUTH APP[4]) 


NOTE: The current release does not specify mapping from the Re PIR into the RSVP 
Path POLICY_DATA object. 
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8.2 



Pull Mode 



8.2.1 RSVP Resv to Re CCR Parameter Mapping 

When, in accordance with clause 7.2.2, the RCEF/BTF sends a CCR request to RACS to request resource reservation as 
a resuh of a received RSVP Resv message, the mapping defined in the following table shall be used: 

Table 8.2: RSVP Resv to Re CCR Parameter mapping 



CCR AVP 


Derivation from RSVP Resv 


Flow-Description AVP 


It shall be mapped from the SESSION and FILTER_SPEC objects: 

• Source Address shall be set to FILTER_SPEC IP Source Address. 

• Source Port shall be set to FILTER_SPEC Source Port. 

• Destination Address shall be set SESSION IP Destination Address. 

• Destination Port shall be set to SESSION Destination Port. 

• Protocol shall be set to SESSION Protocol Id. 


QoS-lnformation AVP 


It shall be mapped from the FLOWSPEC object: 

• QoS-lnformation AVP -> IVIax-Requested-Bandwidth-DL shall be computed from 
FLOWSPEC Peak Data Rate. 

• QoS-lnformation AVP ->Traffic-Descriptor-DL-> Committed-Data-Rate shall be 
computed from FLOWSPEC Token Bucket Rate. 

• QoS-lnformation AVP ->Traffic-Descriptor-DL-> Committed-Burst-Size shall be 
mapped from the FLOWSPEC Token Bucket Size. 
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